NITRO: Таблиці

Категорії: дизайн та імплементація контрольних елементів NITRO, технічне завдання.

Ми вже показали в попередній статті, як проходить формальна розробка контрольного елементу NITRO на прикладі #comboLookup. У цій статті хочемо навести інший приклад, фундаментального з точки зору ERP систем, контрольного елементу для дистанційного відображення відсортованого датасету на стороні сервера за допомогою тонкого клієнта та реактивного протоколу. На цей раз покажемо процес розробки контрольного елменту у повному виробничому циклі.

Загальний цикл розробки контрольних елементів

Створення контрольних елементів поділяється на три етапи:

1) Створення ТЗ з функціональними вимиогами та мотивацією;
2) Технічна специфікація, модель та імплементація Erlang/Elixir/JS;
3) Документування на офіційних сторінках NITRO.

1. Технічне завдання

Основна мотивація. Створення контрольного UI елемента для відображення відсортованих великих датасетів у табличному вигляді на стороні тонкого клієнта з контрольованим курсором на стороні сервера.

Основною мотивацією створення такого спрощеного елементу є елімінація будь-яких видів сортувань як на стороні клієнта так і сервера. Для імплементації класичної вимоги до табличних контрольних елементів — сортування колонок, застосовується набів уже відсортованих за певним критерієм (колонкою) списків об'єктів. Кожен об'єкт який попадає в основний датасет проходить реіндексацію згідно усіх критеріїв. Цей підхід дозволяє значно спростити архітектуру реєстрових таблиць як на стороні клієнта так і на стороні сервера (відсутність кешу на клієнті та повна відсутність сортувань), при цьому користува отримує безпосередній доступ до курсора на стороні сервера.

Для забезпечення складних випадків, коли (мульти)-індекси важко або неможливо побудувати засобами сховища (лімітовані розподілені KV сховища), сортування відбувається функціями користувача які занадто дорого реіндексувати. Використовується інший механізм пошуку, а саме пошук за допомогою асинхронних пошукових воркерів. Для певного несортованого фіду запускається пошуковий процес, який послідовно перебирає усі об'єкти сховища, знаходить відповідні до критерію пошуку, та асинхронно передає їх на клієнт. У випадку коли клієнт покидає сторінку або починає новий пошук, пошуковий процес повинен завершитися. Цей підхід уже апробований та добре себе зарекомендував для швидкого прототипування довільних таблиць та правил пошуку та сортування часу виконання на стороні сервера.

Функціональні вимоги. Основні вимоги, які не залежать від вибору технології реалізації:
— Робота у вікні фіксованої висоти у рядках;
— Обмеження швидкості реакції відповіді (backpressure);
— Автоматична робота по відсортованих джерелах даних;
— Мінамальний розмір клієнтського та серверного коду;
— Підтримка пошукових асинхронних процесів;
— Відсутність горизонтального скролу таблиці;
— Повний контроль за допомогою клавіатури;
— Базовий протокол: init, seek, next, prev.

2. Дизайн та імплементація

Оскільки ТЗ було складене для імплементації контрольного елменту NITRO, формальна модель та специфікація буде надаватися на мові Erlang.

Техноробочий проект NITRO TABLE пропонується опублікувати на Github для виконавця.

1) Створення ТЗ з функціональними вимиогами та мотивацією;
2) Технічна специфікація, модель та імплементація Erlang/Elixir/JS;
3) Документування на офіційних сторінках NITRO.

3. Документування та тестування

Контрольний елемент повинен відповідати рівню Г5, у номенклатурі рівнів відповідності КЗЗ, як визначено документом НД ТЗІ 2.5-004-99. Тому повна формальна специфікація усіх об'єктів, їх зв'язків з відповідними протоколами повинні бути повністю визначені в документації, так само як і доведення властивостей моделі та її коректності на всіх наборах даних. Головним критерієм відповідності нормативам КЗЗ — це жорсткий контроль перфікса дерева по якому відбувається пошук, так як вихід за його межі означає порушення системи захисту інформації.

Після формального визначення об'єктів та протоколів в man/index.htm, контрольний документ публікується в Storyboard контрольних елементів NITRO.

Для автоматизації тестування UI слід використовувати casper.js

Додаток 1

Перелік функцій на стороні JavaScript для реалізаціі мінімального клієнта N2O NITRO протоколу:

token() — поточний токен сесії
qi(name) — DOM елемент по існуючому id
qs(name) — пошук DOM елементу
qn(name) — створення нового DOM елементу
is(x, num, name)
co(name) — отримання cookies (застаріло, використувуємо localStorage)
querySource(name) — отримання преформатованої змінної поля value
validateSources(list) — провалідувати поле value для списку елементів
N2O_start() — створення веб-сокет каналу
$bert — реалізація бінарного берт протоколу на JavaScript
$io — IO протокол (евалуатор та помилки)
$file — FTP протокол (трансфер великих файлів до 100ГБ)
$ws — вебсокет транспорт
transports — транспорти
protos — протоколи

— NITRO — Загальна інформація про веб-фреймворк NITRO
— N2O — Опис контейнера протоколів та сервісів N2O
— N2O NITRO — Опис протоколу веб-фреймворку
— BERT.JS — Опис бінарного протоколу